Is it Y2K compliant?
The original 3CServer (on which 3CDaemon is based) was written as a piece of *freeware* by myself. It is not an "officially" supported 3Com product - It has no 3C Number, does not appear on any product list. I just saw a need and wrote the software to fill it. I am an employee of 3Com, but wrote the server in my spare time.
Then, 3Com Network Management Division (NMD) saw the server, and liked it. Seeing an opportunity for wider distribution of the program, I gave NMD the code. They produced a slightly modified version (different icons, other cosmetics, the core code remains the same) based on 3CServer 1.1.007. This became part of the NetBuilder II Remote Upgrade Utilities Version 11.0. (RUU). 3CServer will also be part of Transcend NT Version 1.1.
So, is 3CServer/3CDaemon Y2K compliant?
All of the functions which use a date including a year, use the Microsoft function CTime, which is accurate up to the year 2038. I have done some testing. What I did was go through the code and looked for every instance where I used a date with includes a year designation. In every case, dates which are post-2000 were rendered correctly. So, as far as I can determine, 3CServer is Y2K compliant. However, this is me speaking as an individual (and the developer of the freeware code), not as a representative of 3Com.
3CServer will be included as part of the Transcend NT 1.1 Y2K compliance tests.
So, even though 3CDaemon already passed all my tests for Y2K compliance, it is usually considered bad practice for the person who developed the code to also test and certify it. If you wish a version that has been independantly tested, consider Transcend NT 1.1.
In either case, 3CDaemon never does any computations where it compares one date against another. Thus, it's difficult to imagine what Y2K issues it could have...
Differences from Berkeley TFTP Daemon
3CDaemon is designed to be as user-friendly as possible. While the Berkeley Tftp daemon
concentrates on security, 3CDaemon concentrates on ease of use. The main differences are:
Limitations:
The following FTP commands are not implemented, just because they didnt seem applicable: ACCT, SMNT, STOU, ALLO, SITE
In addition, some other commands are implemented but with some limitations:
LIST and NLST do not support switches. Any switches are parsed off the command line, and a standard file listing is returned.
The TYPE command will accept ASCII or BINARY. EBCDIC is not supported.
The MODE command only supports type Stream
The STRU command only supports type File
The Syslog server, unlike some syslogd implementations, does not apply a host name to received messages. Messages are always logged as dotted decimal IP addresses. This would be easy enough to implement, but I am concerned about the latency problems in doing a host lookup for every message (especially if the messages are coming fast and furious!)
Where do I report bugs/request enhancements?
Email dan_gill@3com.com